perm filename MBOX.DGL[UP,DOC]17 blob
sn#400256 filedate 1978-12-05 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00017 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 Abstract
C00004 00003 MUSBOX help message.
C00005 00004 Samson box output
C00025 00005 Bells and whistles for MUSBOX output.
C00040 00006 The scanner-parser
C00041 00007 Filename handler and conventions
C00047 00008 Interactive mode.
C00048 00009 Setting timing variables for Samson box output:
C00051 00010 PRINT statement, strings, RDNUM.
C00053 00011 Things available to instrumens from MBOX.
C00055 00012 What each instrument is handed by the scanner
C00063 00013 That's about all you need to know. If you have any questions,
C00073 00014 If you want your instrument to have a default F1 function like MUSCMP,
C00081 00015 If you want to preset the P fields in MBOX to default values,
C00082 00016 BNF of MUSBOX
C00092 00017 ∂22-Nov-78 1700 DGL New whiter, brighter MBOX.
C00103 ENDMK
C⊗;
Abstract
This describes the program MUSBOX, written by Gareth Loy,
which is an interpreter-compiler for generating commands for the
Systems Concepts Digital Synthesizer.
At SUAI the system version of this program is SYS:MBOX.
The input language is made to resemble MUSCMP so as to be compatable
(insofar as is reasonable) to software music compilers of the
MUSIC5, NEWMUS, MUSCMP variety.
MUSBOX help message.
(This is actually more like a helpless message.)
If MUSBOX sent you here, it is likely that what you said to MUSBOX was something
it couldn't understand.
When it complains, it first tells you it is doing so, then it prints what
it thinks is wrong, then it tries to show you the line of code in your
input that caused it to barf on you.
If the error doesn't make sense to you, find someone to whom it does.
There is currently no listing of error messages and what they likely mean,
because it would change daily (sigh). In essence, punt.
Samson box output
There is code for
Samson instruments predeclared in MUSBOX. (For a list of the available
instruments, see previous page.
They perform a variety of simple functions such as sinusoid generation,
fm, filtering, reverb, etc.
They are able to use functions created by
JAM's SEG record generating program, SYS:TFUN (If you
don't know about this, some documentation is available in INTERM.TXT[DOC,MUS],
under the subject of FUNED and EDFUN, there is also in the program itself)
or Leland's FUNC program (see LCS).
Unlike MUSCMP (that is, NEWMUS and MUSIC and friends) instruments in MUSBOX
are capable of running more than one copy of themselves at a time.
When MUSBOX runs an instrument, it instantiates a copy of the values
passed to that instrument for each time the instrument is called.
In essence, the code for each instrument is a "template" of the actual
instrument that is run. In this way, if you want an instrument to play
two notes at the same time, the program SPROUTS two copies of this template,
keeping the values passed to the instruments from the PLAY block seperate
for each instantiation or sprout of the instrument template.
In short, overlapping the same instrument with itself will work (up to the
limit of the Samson box hardware = 256 oscillators, 128 modifiers).
Here's an example of an input file: (Reserved words are capitalized.)
PLAY;
SIMP 0 .5 A 1 F1 outa;
FINISH;
PLAY caused MUSBOX to begin looking for instruments to run.
You say PLAY when you want MUSBOX to start writing out commands, so it opens
an output file. It uses the default output filename of TEST.SAM. If you
with to call the output file something else, put the name after PLAY (e.g.
PLAY FOO; will cause the file FOO.SAM to be written). SIMP is an instrument
predefined in the system version of MUSBOX, the numbers after it are the
things the instrument needs to know to play. The meanings of these numbers
are relative to what the instrument expects to get, so you must consult
the previous page for a description of SIMP.
The FINISH statement stops command output, forces all instruments not yet
run to do so and prompts for more input.
Bells and whistles for MUSBOX output.
Declarations, etc.:
------------------------------------------------------------------------
VARIABLE takes a string of names as arguement, delimited by spaces
and/or commas, which MUSBOX will treat as REALs. (Everything in
MUSBOX is handled as a REAL and only fixed when necessary.) These
variables are stored in a parallel array system,
and can be used in any expression context such as
assignment statements,etc.
INSTRUMENT takes a template name as its first argument then any number
of other unique identifiers which will be associated with
this template;
COMMON same as INSTRUMENT, but someday INSTRUMENT will be redefined
to cause MUSBOX to look up a .REL file full of instrument code
and read it in. At that time COMMON will be the only way
to associate a template with a series of other identifiers
that you want to also point to that template;
PLAY begins a PLAY block. May be followed with an optional argument
specifying an output file, which will have the default extension
".DOA" for SAMSON box output or ".PLA" for FRM output. No
filename defaultts to "TEST" plus extension. Or, instead
of a filename you can say "ASK" and MUSBOX will prompt the user
at execution time and get the filename that way.
Entering a PLAY block initializes lots of things as described
below;
It is legal to say PLAY inside a PLAY block (i.e., PLAY-FINISH
do not really constitute a block boundary pair). This does the
same thing as resetting the pass counter to 0 (see below). In
this way it is possible to concatenate play lists.
FINISH Ends a PLAY block, forces all instruments to quit, closes
the output file. An optional argument after the FINISH statement
specifies the number of seconds to wait after the end of the
last instrument before turning off the dacs and doing a reset;
RECORD takes a filename with default extension ".FUN" and uses
a special handler to read in SEG functions. Knows about "ASK";
INSERT takes a filename with default extension ".SAM", suspends
execution of current level, jumps to the new file and
continues execution there, returning to this level when
that is exausted. Files can be inserted up to 15 deep.
.FUN files can also be read in this way by adding the
explicit extension. Knows about "ASK";
EXIT forces MUSBOX to quit and returns you to the monitor, after
closing all files, and runs SAMX with the output filename.
DONT_SCAN stop scanning statements until you see:
SCAN which turns scanning back on. This is useful for making
MUSBOX ignore part of the score.
************************************************************************
User settable variables to set before entering PLAY block:
The following variables are tested by MUSBOX when it scanns a PLAY
statement to set overall conditions. To have any effect, therefore, they
must be set before issuing the PLAY statement.
------------------------------------------------------------------------
boxtyp assign either samdev or frmdev to determine the type of
output. This is also settable by
having your input file have either extensions .SAM
or .FRM respectively.
defaults to samdev;
nptix assign to how many processing ticks, defaults to 96;
nutix assign to how many update ticks, defaults to 32;
ttix total of the above two, this determines the sampling rate;
srate will contain sampling rate calculated from nptix and nutix;
mag will have frequency scaling calculated from srate;
pass this is the pass counter, used to determine where we are in
the flow of time. It is basicly for use by wizards
but the following can be done with impunity. To reset the
pass counter to 0 after a run of instruments so that the next
run can start from zero again type after the first set PASS←0;
noutchans assign between 0 and 4 output channels,
defaults to quad;
whichside assign 0 for dacs to read from generator sum memory only,
positive for modifier side only, negative for both sides,
defaults to negative;
filters for low pass filters on the dacs, assign any of these values:
"unfiltered" ≡ bypass analog filters,
0 ≡ 4.5 kHz
1 ≡ 9.0 kHz
2 ≡ 13.5 kHz
3 ≡ 18.0 kHz,
defaults to 3;
packing set to left_justified, right_justified or full_word,
defaults to full_word which is interpreted by LOWER to
only load full_word when necessary;
optimization set to OPTIMIZE or NON_OPTIMIZE to determine whether
LOWER will pack more commands per word where possible,
defaults to OPTIMIZE;
debug assign with any summation of
debug_instruments to see what values they are passed,
debug_scanning to see what is read in from a file,
debug_arithmetic to see how MUSBOX does it's arithmetic,
debug_stack to see the contents of arithmetic stacks,
debug_scheduling to see how MUSBOX sprouts instruments;
************************************************************************
Variables preset by MUSBOX:
All of the following are set up when you issue a PLAY statement.
They will not be assigned actual values until then! These are writable
variables, so if you want to clobber them you can. No guarantees, however
that doing so will get you anywhere.
------------------------------------------------------------------------
zero predeclared sum memory location to always return zero;
outa, outb...d predeclared sum memory locations to stuff generator output;
outma, outmb..d predeclared sum memory locations to stuff modifier output;
************************************************************************
Reserved procedures in MUSBOX:
These claim and return the address of the next free sum memory
location. They require initialization induced by the PLAY statement, and their
results are invalid outside a PLAY block.
------------------------------------------------------------------------
gen_sum returns the next free last pass sum memory location;
mod_sum likewise for modifiers;
print prints the subsequent argument on the user's screen;
rdnum returns a real number from the user;
getdm takes length of delay memory desired as argument,
returns base address if successful in claiming memory,
else generates error(under development);
rand returns a random number;
************************************************************************
Preloaded variables:
These variables are set up when MUSBOX is entered and are valid
anywhere. They are assigned the values indicated below them.
------------------------------------------------------------------------
A,AS,B,C,CS,D,DS,E,F,FS,G,GS;
440,466.16,493.89,261.62,277.18,293.66,311.13,329.63,349.23,369.99,391.99,415.31;
************************************************************************
Symbolic constants:
These are predeclared symbols. They cannot be assigned to,
but may be assigned from (e.g. a←pi, but not pi←a).
-------------------------------------------------------------------------
Generators:
g_inactive, g_pause, a_running, b_running, g_wait, c_running,
data_read, data_write, dac_write,
lplusq, lminusq, lexpplus, lexpminus,
sum_of_cosines, sawtooth, square, pulse_train, sine, sin_fm;
Modifiers:
m_inactive, u_noise, tr_u_noise, latch, threshold, invoke_delay_unit,
notwopoles, two_0poles, two_1poles,
notwozeroes, two_0zeroes, two_1zeroes,
int_mixing, one_pole, mixing, one_zero,
four_quad_multiply, am,
maximum, minimum, signum, zero_crossing_pulser,
add_sum_memory, replace_sum_memory;
Delay units:
delay,
d_inactive,
delayline, table_lookup, round_table_lookup;
Debugging:
debug_instruments, debug_arithmetic, debug_scheduling, debug_scanning,
debug_stack,debug_records,debug_template;
Initialization:
samdev,frmdev,
unfiltered,
optimize,non_optimize,
right_justified,left_justified,full_word;
Misc. commands:
pause_clear,wait_clear;
Constants:
pi,
true,false;
************************************************************************
Misc. things:
------------------------------------------------------------------------
COMMENT can be used to enter comments in the text, everything scanned
until the first semicolon is seen will magically disappear;
<, ∂ these are also comment charactors and cause MUSBOX to flush the
entire input line. It does not break on a semicolon, but flushes
everything until it sees a <crlf>. SO DON'T PUT ANY STATEMENTS YOU
WANT TO HAVE EXECUTED ON THE SAME LINE AS "<" or "∂";
' When this charactor is scanned at the beginning of a number
the immediately subsequent value is presumed to be in octal.
↓ This charactor cause a <cr><lf> to be printed on the user's terminal;
ASK When supplied as an argument anywhere that a filename is expected,
MUSBOX will prompt the user for a filename instead of taking
one from where the ASK statement was found.
See the description of the filename scanner.
(e.g. PLAY ASK; at the head of a PLAY block
will cause the filename handler to prompt the user for
an output file (with .SAM extension implicit). RECORD ASK;
will cause the filename handler to prompt the user for a function
file (with .FUN implicit)).
************************************************************************
The scanner-parser
MUSBOX has an inverse Polish expression scanner that works in
the usual fashion.
Precedence of operators is:
[")"]["¬"] unary negation
["↑"] exponentiation
["*"]["/"] ["⊗"] left shift
["+"]["-"]
["("]["←"]
Multiple operations of the same precedence are done left to right.
Filename handler and conventions
MUSBOX has one filename handler for all the different kinds
of files it reads. In all the modes that follow, it is possible to
put in any number of filenames (seperated by a comma or
space, or whatever) and they will be acted on in turn.
Partial filename specifications are always allowed.
Depending on the context of the filename request, certain
file extensions are defaultable.
There are three levels of input to MUSBOX: FILE PROMPT level,
TTY INPUT level and FILE INPUT level
FILE PROMPT level is what MUSBOX does when it says
"Input file:".
If the <filename> extension is not supplied, MUSBOX looks for a sequence
of files with the following extensions: .HED, .SCR, .BOX. If you want
to input a file that has no extension, you must say <filename>.. (that's
right, a period after the filename).
If a filename is found, a lookup is immediately done and command switches
to the contents of that file.
If <alt> is typed, then MUSBOX exits back to the monitor.
If <cr> is typed, MUSBOX goes to TTY PROMPT level.
FILE input level is when MUSBOX is snarfing down a file that
you pointed it to. This level and TTY level are handled identically,
so whatever you say in a file you can also type in at a TTY and vice
versa. When the file is exausted, you are returned to FILE PROMPT level.
TTY INPUT level prompts with a ">". As far as MUSBOX is concerned,
this input mode and FILE INPUT level are identical.
To return to FILE PROMPT level, type <alt>. (The next <alt> would exit MUSBOX.)
There are, however some special commands available at TTY level. For
a discussion, see the page on Interactive Mode.
Files can be read in at other than at FILE PROMPT level.
The following commands work for either TTY or FILE INPUT level.
INSERT can be used to switch to another file for further processing
of commands. Execution of the new file begins immediately. More than
one file can be specified, and they are taken in turn. The INSERTed
file can in turn do an INSERT, and these can nest to the level of 15 deep.
It has the same filename extension defaults as FILE PROMPT level.
RECORD input statement accepts the default .FUN extension, otherwise
it behaves exactly like the other input modes. This .FUN extension is the
usual one put on files containing SEG or SYNTH functions.
(Leland C. Smith memorial feature #1) In addition the term FUNC
behaves exactly like RECORD.
The PLAY statement takes an optional argument for the name
of the command output file. Default filename is TEST, default extension
is .SAM.
In addition, until the time that a PLAY statement is scanned, you
can say (Leland C. Smith memorial feature #2) OUTPUT <filename> (defaults
the same as PLAY).
For the filename argument of all of the above (INSERT, RECORD, FUNC,
PLAY and OUTPUT) you can substitute the term ASK. In this case, MUSBOX
will prompt the user for a filename instead, keeping the default extensions
appropriate for the command.
NOTE: MUSBOX has a seperate scanner for function files (things
with .FUN extension). This scanner is usually invoked by saying
RECORD <filenames>; This scanner can be invoked from FILE PROMPT level
by explicitly writing the filename extension of the first file.
For example, these are the same:
>RECORD FOO BAZ BAR;
and
Input File: FOO.FUN BAZ BAR
Interactive mode.
The following commands at TTY level have these effects:
In all versions of MUSBOX:
<filename>αβε Edit the named file. If no filename, then edit
the last file opened by MUSBOX.
<filename>αβP Play the named file through the Samson box.
Asks for # times to play, wait, type <alt> to abort.
In MUSBOXE (SYS:MBOXE at SUAI)
<function>αβE Edit function with EdFun. Type HELP after entering
EdFun for a list of commands.
<filename>αβW Write out functions to named file. (.FUN default)
Setting timing variables for Samson box output:
You can now set any of srate, mag, ttix (total ticks), nptix
(number of processing ticks) or nutix (number of update ticks) and
the remainder of these variables will be set to reasonable values
(it sez here). Hence, you can say srate←25600; and the right things
get done to accomplish that. However, do not try to reset any of
these variables inside a play block, as unpredictable things
will happen.
Additional warnings: The "right thing" may not always be
unambiguous, and MUSBOX does what it can. For instance, simply
setting ttix does not specify the division between nptix and nutix,
so this is defaulted to a rather arbitrary ratio between the two
(3/1). This ambiguity can be overcome by setting nptix and nutix
yourself, but letting MUSBOX do it should be ok most of the time.
Also, since the thing that really determines the sampling rate
is the integer ttix, setting srate (which is a real) will give you
instead the srate calculated from the nearest integer value of ttix.
Everything else is set from this also. So if the srate you get is
not exactly the srate you set, that's why.
Processing ticks are restricted to be ≥2 and ≤256.
Update ticks are restricted to be ≥2.
Total ticks are always 8 more than the sum of update and processing
ticks (to account for overhead ticks).
The numbers actually compiled into the SAM command stream
will be slightly different, reflecting how the box likes to think
about these things, that is:
Highest tick will be ttix-2. This is because the counter must
start at 0, and be one less than the number required (see the spec.).
Highest proc. tick will be nptix-1 also because counter must start
at 0, again as per spec.
PRINT statement, strings, RDNUM.
There is a print statement that you can do all sorts of
bizarre things with such as:
PRINT "now replace a with b",a←b;
PRINT -(1/(2↑.5)*pi,"look ma no hands",1 ⊗ 20;
PRINT also works for getting information about functions.
PRINT amp1;
will give you its type, where it is on the list, the number of elements,
etc.
PRINT INSTRUMENTS;
will print out the list of instruments loaded.
The charactor "↓" is reserved in MUSBOX and prints out
a carriage return - linefeed on the users terminal. Strings
must be surrounded by quotes, quotes within quotes are not supported.
RDNUM takes a string argument from the user and returns
it to MUSBOX. The following asks for a number and deposits it in A;
PRINT "Type your mother's birthdate",↓;
A←RDNUM;
Things available to instrumens from MBOX.
external procedure BoxError(string errmsg);
Invokes MBOX's error handler with your message.
external boolean procedure getRecord(string name;
reference record_pointer(any_class) r;
record_pointer(any_class) Tops);
Searches a linked list for a record name matching the string name.
Searches the list pointed to by Top, returns the pointer in r.
external procedure LinkUp(
reference record_pointer(any_class) lstTop;
Record_Pointer(any_class) lstTmpTop;
integer lstTyp(functionList));
This is used to link the record named in lstTmpTop
to the list named in lstTop.
external record_pointer(InsCls) insTop;
Points to the top of the instrument linked list.
external record_pointer(InsCls) funTop;
Points to the top of the function linked list.
External real srate,mag;
Has the value of the sampling rate and mag.
What each instrument is handed by the scanner
A record pointer named Pns is passed to each instrument. It points
to a record which contains all the fields that the scanner
scanned for this instantiation of the instrument. It includes the
following:
1) Three parallel arrays, one real, one of type record_pointer(any_class)
and one of type string.
These arrays contain all the fields that the scanner found for this instrument
from P0 out to the current maximum of P128. The real array contains
the values parsed from arithmetic expressions, the record_pointer array
contains record pointers to the SEG functions to be used by the instrument
for such things as amplitude and frequency control through time.
The string array is special, and contains the string representation of
the field as it was scanned by MBOX, but without intervening spaces between
elements of the field.
For instance,
if the scanner saw a PLAY list that looked like this:
PLAY;
SIMP 0 1 A AMP1 1 + 2 + 3 OUTA;
FINISH;
(where SIMP is the name of an instrument, A is a predeclared variable
that returns the value 440,
OUTA is a predeclared variable
containing the addresses of a sum memory location,
and finally, AMP1 is a SEG function that has been read in from a file),
then the fields presented to the instrument
on the three parallel arrays will be as follows:
array element number:
0 1 2 3 4 5 6
value in string array:
"SIMP" "0" "1" "A" "AMP1" "1+2+3" "OUTA"
value in real array:
debug 0. 1. 440. 0. 6. 384.
value in record_pointer array:
SIMP nr nr nr AMP1 nr nr
We see that only one SEG record was passed to this instrument in P4
(nr is used here to mean "null_record", i.e., no record is being pointed to).
A record_pointer to SIMP shows up in P0 of the record_pointer array.
Remember that instruments are named in P0, so this field points to the instrument
descriptor record. You can find out useful things about the instrument
from this, but I won't go into details.
On the real array, we see the result of 1+2+3 and the address of
sum memory location OUTA (384).
In the real array, the meaning of debug is this: since P0 is
reserved for the record_pointer to the instrument linked list, no number
can occupy P0. So instead, a debug flag is placed there which the instrument
can interpret. When a user says soething like
DEBUG←DEBUG_INSTRUMENTS;
to the scanner, the scanner turns on a certain bit in the debug flag.
This flag is copied into the real array when the instrument is called.
An instrument can subsequently test to see if this bit is on, and if it is,
can then do various things, such as print out to a teletype the values
it was passed so the user can see if they agree with what he thinks should
be there.
That's about all you need to know. If you have any questions,
I just stepped out...
If you want your instrument to have a default F1 function like MUSCMP,
then put this code somwhere in your instrument file (like maybe the last page).
internal record_pointer(any_class) array rPrms[0:prmLen];
procedure MakeF1;
begin
record_pointer (any_class) foo;
foo←New_Record(seg);
newArray(real,seg:times[foo],[1:4]);
newArray(real,seg:values[foo],[1:4]);
seg:name[foo]←"F1";
seg:type[foo]←0;
seg:maxval[foo]←1;
seg:minval[foo]←0;
seg:maxtime[foo]←100;
seg:mintime[foo]←0;
seg:nsegs[foo]←4;
seg:times[foo][1]←0;
seg:times[foo][2]←25;
seg:times[foo][3]←75;
seg:times[foo][4]←100;
seg:values[foo][1]←0;
seg:values[foo][2]←1;
seg:values[foo][3]←1;
seg:values[foo][4]←0;
Linkup(top,foo,functionList,false);
RPrms[5]←foo;
end;
require MakeF1 initialization;
If you want to preset the P fields in MBOX to default values,
then do something like this, and put it on or about the last page
of your instrument file.
procedure SetupPns;
begin
∂ SIMP Beg, Dur, Freq, ampScl, ampRec, outAamp,outBamp,outCamp, outDamp;
∂ 0, 0, .5, 440, .3, 0, 1.0, 1.0;
$prms[2]←.5; sPrms[2]←".5";
$prms[3]←440; sPrms[3]←"440";
$prms[4]←.3; sPrms[4]←".3";
$prms[6]←1; sPrms[6]←"1";
$prms[7]←1; sPrms[7]←"1";
end;
require SetupPns initialization;
BNF of MUSBOX
Take this with a grain of salt...
<play_block> ::= PLAY; <play_list> |
PLAY <filename>; <play_list>
<play_list> ::= <instrument_call>;<play_list>|
<statement_list>;<play_list>|
FINISH
<statement_list>::= <statement_list><statement>
<statement> ::=<null> | <reserved_word> | <field_list> |
<instrument_call> | <procedure_call>
<instrument_call>::= <instrument_identifier> |
<instrument_identifier><field_list>
<procedure_call>::= <procedure_identifier> |
<procedure_identifier> ( <field_list> )
<field_list> ::= <field> | <field_list><field_mark><field>
<field> ::= <expression> | <record_pointer> | <instrument_identifier> |
<procedure_call> | <delimited_string_constant>
<field_mark> ::= <space> | <comma> | <tab> | <cr> | <ff> | <lf>
∂22-Nov-78 1700 DGL New whiter, brighter MBOX.
To: "@MUSIC.DIS[DOC,MUS]"
SUMMARY: (for details, see below.)
1) New version of MBOX.REL[SAM,MUS].
1a) New SYS:INSCOM is compatable with new MBOX. Old one is now SYS:INSCOM.OLD.
New INSCOM accommodates the modular approach in (5) below.
2) MBOX.HDR[SAM,MUS] no longer needed, everything is in SAMLIB.HDR[SUB,SYS].
3) New features:
a) can play .SAM files from MBOX (αβP).
b) FINISH and EXIT no longer run SAMX because of 3a.
c) optional function editing package allows online editing of SEG
functions with EDFUN, (αβE)
and the ability to write them out to the disk (αβW).
d) new mode for fast interactive parameter tweeking/playing (αβQ).
e) can go directly to file from MBOX on command (αβε).
This enables E's αβRUN command to be used more effectively.
f) new options in error messages.
g) optimize mode is now default (was non_optimize). Should cut down
substantially on number of commands assembled.
h) Values for WHICHSIDE now have symbolic names.
4) Enlarged access to MBOX's symbol tables.
5) New modular system for instruments, cuts compilation time and
disk space for storing instrument object code.
1) Changeover to new MBOX.
Saved old version: MBOX.OLD[SAM,MUS←MBOX.REL[SAM,MUS
New version: MBOX.REL[SAM,MUS] and MBOXE.REL[SAM,MUS], MBOX.SAI[SAM,MUS].
1a) New INSCOM.
INSCOM.OLD←SYS:INSCOM.DMP
(New) SYS:INSCOM.DMP, INSCOM.REL[SAM,MUS]
(XCOM.DMP,.REL[SAM,MUS] is now merged into INSCOM, use it instead.)
2) Only one change to user instruments required, in your instrument file
eliminate the line:
require "MBOX.HDR[SAM,MUS]" source_file;
from page 2 of your instrument file. That's all.
(There are further changes described in (5) below that are optional
which result in faster compilation.)
3a,b) MBOX.REL[SAM,MUS] now compiled to not
run SAMX when it sees finish. Instead, it is now possible to play
directly from MBOX. MBOX is now enabled to run Tovar's SAMPLA program
as a phantom job.
The following sequence shows how to use the SAMPLA feature.
User actions are in "[]".
.RU MBOX
MUSBOX: 09-NOV-78
Input file: [CR] type <cr>.
>FOOαβP type filenameαβP. (default: TEST.SAM)
sampla is job 34 SAMPLA is cranked up.
Type # times to play (wait) the wait feature is not implemented.
# [CR] <cr> plays it once.
PLAY 1 0...........! MBOX tells SAMPLA to play.
# [ALT] ABORTING ! typing <alt> kills SAMPLA, returns to MBOX.
> DON'T TYPE <CALL> WHILE RUNNING SAMPLA!
MBOX asks for a number
of times to play (and wait) which defaults to play 1 time.
(The wait feature is not yet implemented in SAMPLA.)
To quit, type <alt>. DO NOT TYPE [CALL]!!!
There are still some limitations which should go away soon (I hope).
It does not tell you if someone else is already using it and you
must wait, and it does not automatically map your audio speaker.
The "PLAY 1 0.......!" is an indication of how many times MBOX had to send the
message to SAMPLA before it could receive it.
(In the event that MBOX looses it's connection to SAMPLA, you may have to
kill SAMPLA from the monitor. Type .KILL <job_#> to do this.)
3c) MBOX can now also edit and write out functions.
That is, it can be loaded with EdFun and SSWrt. MBOXE.REL[SAM,MUS]
has this feature, and is in all other respects identical to MBOX.REL, exept
of course that it is bigger.
To use this feature, read in a record file with your favorite command
and then to edit a function, type to the ">" prompt: <function_name>αβE.
This enters EdFun. Type HELP to EdFun for assistance. αβE to EdFun exits
back to MBOX's ">" prompt after updating the changes to the function.
Typing <alt> to EdFun cancles any changes and returns.
To write out the updated functions into a .FUN file type:
<file_name>αβW.
3d) Fast interactive play mode: useful for changing a parameter and hearing
the results with a minimum of typing or file shuffling.
The command to invoke this is αβQ and it has the following effects:
1) effect a PLAY statement.
2) effect a call to the last instrument MBOX ran.
3) effect a FINISH statement.
4) effect a αβP command.
With this command it is possible to set up a call to an instrument, change
one P field and go back and hear it as quickly as MBOX will ever be able
to do it. For example, the following is an abridged sequence using αβQ:
>play;
>simp 0 1 a 1 amp1 outa;
>finish;
>p5←amp4;
>αβQ Output file: DSK:TEST.SAM[SAM,DGL]
Finishing command output file DSK:TEST.SAM[SAM,DGL]
sampla is job 25
Type # times to play (wait)
#
and so on. Only one instrument can be played in this fashion, the last
instrument MBOX scanned. (This may be expanded.)
3e) New command exits to E editor with a specified filename.
Command is <file_name>αβε. Default file is the last file you read
in to MBOX, or if none, then to the last file you ever edited.
As always, partial filename specs are ok.
When you wish to return from E to MBOX type αβXRUN.
(Please note that there are times when E can't return you to MBOX, so
you must .RU MBOX again.)
3f) New options in error messages: <lf> continues to print error
messages, but does not require a <cr> to continue execution.
Q<cr> will not even print the error messages. (Also known as BIL mode!)
To return to prompting for error messages, type <esc>I which clears
both <lf> and Q.
3g) Default setting for optimization flag is now optimize, was
non_optimize. While this can cause a substantial reducion of commands
to be compiled, it may (but shouldn't) cause other problems.
3h) WhichSide now has symbolic values: gen_side,mod_side,both_sides,
which can be used instead of 0,1 and -1. It still defaults to both_sides.
4) Users can now access values in MBOX's symbol tables at runtime.
MBOX.HDR[SAM,MUS] has been reserected to provide the necessary external
symbols for this. (It is entirely optional.) This can be used to
search for declared variables, functions, instruments, etc. so that for
instance, an instrument can test the value of a variable not passed to it,
etc. See MBOX.HDR[SAM,MUS] for details.
5) New modular approach to instrument construction. Savings in
compile time and loading (and consequent thumb twiddling) range
up to 90%. See SAMINS.DMO[SAM,DGL] for a complete description.
-Gareth←bugs